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' 15 Field of the Invention 

The present invention relates to network 
communications and more particularly to network 
communications to a cluster of data processing systems. 

2 0 Background of the Invention 

The Internet Protocol (IP) is a connectionless 
protocol. IP packets are routed from originator through a 
network of routers to the destination. All physical 
adapter devices in such a network, including those for 
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client and server hosts, are identified by an IP Address 
which is unique within the network. One valuable feature 
of IP is that a failure of an intermediate router node or 
adapter will not prevent a packet from moving from source 
5 to destination, as long as there is an alternate path 

through the network . 

In Transmission Control Protocol/Internet Protocol 
(TCP/IP) , TCP sets up a connection between two endpoints, 
identified by the respective IP addresses and a port 

10 number on each. Unlike failures of an adapter in an 

intermediate node, if one of the endpoint adapters (or 
the link leading to it) fails, all connections through 
that adapter fail, and must be reestablished. If the 
failure is on a client workstation host, only the 

15 relatively few client connections are disrupted, and 

usually only one person is inconvenienced. However, an 
adapter failure on a server means that hundreds or 
thousands of connections may be disrupted. On a 
System/390 with large capacity, the number may run to 

2 0 tens of thousands. 

To alleviate this situation. International Business 
Machines Corporation introduced the concept of a Virtual 
IP Address, or VIPA, on its TCP/IP for OS/390 V2R5 (and 
added to V2R4 as well) . Examples of VIPAs and their user 

25 may be found in United States Patent Nos . 5,917,997, 

5,923,854, 5,935,215 and 5,951,650. A VIPA is configured 
the same as a normal IP address for a physical adapter, 
except that it is not associated with any particular 
device. To an attached router, the TCP/IP stack on 

30 System/390 simply looks like another router. When the 

TCP/IP stack receives a packet destined for one of its 
VIPAs, the inbound IP function of the TCP/IP stack notes 
that the IP address of the packet is in the TCP/IP 
stack ^s Home list of IP addresses and forwards the packet 

35 up the TCP/IP stack. The "home list" of a TCP/IP stack 
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is the list of IP addresses which are "owned" by the 
TCP/IP stack. Assuming the TCP/IP stack has multiple 
adapters or paths to it (including a Cross Coupling 
Facility (XCF) path from other TCP/IP stacks in a 
5 Sysplex) , if a particular physical adapter fails, the 

attached routing network will route VIPA- targeted packets 
to the TCP/IP stack via an alternate route. The VIPA may, 
thus, be thought of as an address to the stack, and not 
to any particular adapter. 

10 While the use of VIPAs may remove hardware and 

associated transmission media as a single point of 
failure for large numbers of connections, the 
connectivity of a server can still be lost through a 
failure of a single stack or an MVS image. The VIPA 

15 Configuration manual for System/3 90 tells the customer 

how to configure the VIPA(s) for a failed stack on 
another stack, but this is a manual process. Substantial 
down time of a failed MVS image or TCP/IP stack may still 
result until operator intervention to manually 

2 0 reconfigure the TCP/IP stacks in a Sysplex to route 

around the failed TCP/IP stack or MVS image. 

While merely restarting an application with a new IP 
address may resolve many failures, applications use IP 
addresses in different ways and, therefore, such a 
25 solution may be inappropriate. The first time a client 

resolves a name in its local domain, the local Dynamic 
■ Name Server (DNS) will query back through the DNS 
hierarchy to get to the authoritative server. For a 
Sysplex, the authoritative server should be DNS/Workload 

3 0 Manager (WLM) . DNS/WLM will consider relative workloads 

among the nodes supporting the requested application, and 
will return the IP address for the most appropriate 
available server. IP addresses for servers that are not 
available will not be returned. The Time to Live of the 
35 returned IP address will be zero, so that the next 
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resolution query (on failure of the original server, for 
example) will go all the way back to the DNS/WLM that has 
the knowledge to return the IP address of an available 
server. 

5 However, in practice, things do not always work as 

described above. For example, some clients are 
configured to a specific IP address, thus requiring human 
intervention to go to another server. However, the person 
using the client may not have the knowledge to 

10 reconfigure the client for a new IP address. 

Additionally, some clients ignore the Time to Live, and 
cache the IP address as long as the client is active. 
Human intervention may again be required to recycle the 
client to obtain a new IP address. Also, DNSs are often 

15 deployed as a hierarchy to reduce network traffic, and 

DNSs may cache the IP address beyond the stated Time to 
Live even when the client behaves quite correctly. Thus, 
even if the client requests a new IP address, the client 
may receive the cached address from the DNS. Finally, 

2 0 some users may prefer to configure DNS/WLM to send a Time 

to Live that is greater than zero, in an attempt to limit 
network-wide traffic to resolve names. Problems arising 
from these various scenarios may be reduced if the IP 
address with which the client communicates does not 
25 change. However, as described above, to affect such a 

movement of VIPAs between TCP/IP stacks requires operator 
intervention and may result in lengthy down times for the 
applications associated with the VIPA. 

Previous approaches to increased availability 

3 0 focused on providing spare hardware. The High- 

Availability Coupled Multi-Processor (HACMP) design 
allows for taking over the MAC address of a failing 
adapter on a shared medium (LAN) . This works both for a 
failing adapter (failover to a spare adapter on the same 
35 node) or for a failing node (failover to another node via 
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spare adapter or adapters on the takeover node.) Spare 
adapters are not used for IP traffic, but they are used 
to exchange heartbeats among cluster nodes for failure 
detection. All of the work on a failing node goes to a 
5 single surviving node. In addition to spare adapters and 

access to the same application data, the designated 
failover node must also have sufficient spare processing 
capacity to handle the entire failing node workload with 
"acceptable" service characteristics (response and 

10 throughput) . 

Automatic restart of failing applications also 
provides faster recovery of a failing application or 
node. This may be acceptable when the application can be 
restarted in place, but is less useful when the 

15 application is moved to another node, unless the IP 

address known to the clients can be moved with the 
application, or dynamic DNS updates with alternate IP 
addresses can be propagated to a DNS local to clients 
sufficiently quickly. 

2 0 Other attempts at error recovery have included the 

EDDIE system described in a paper titled "EDDIE, A Robust 
and Scalable Internet Server" by A. Dahlin, M. Froberg, 
J. Grebeno, J. Walerud, and P. Winroth, of Ericsson 
Telecom AB, Stockholm, Sweden, May 1998. In the EDDIE 

25 approach a distributed application called "IP Address 

Migration Application" controls all IP addresses in the 
cluster. The cluster is connected via a shared-medium 
LAN. IP address aliasing is used to provide addresses to 
individual applications over a single adapter, and these 

30 aliases are located via Address Resolution Protocol (ARP) 

and ARP caches in the TCP/IPs. The application monitors 
all server applications and hardware, and reallocates 
aliased IP addresses in the event of failure to surviving 
adapters and nodes. This approach allows applications of 

3 5 a failing node to be distributed among surviving nodes, 
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but it may require the monitoring application to have 
complete knowledge of the application and network adapter 
topology in the cluster. In this sense, it is similar to 
existing Systems Management applications such as those 
5 provided by International Business Machines Corporation's 

Tivoli® network management software, but the IP Address 
Migration Application has direct access to adapters and 
ARP caches. The application also requires a dedicated IP 
address for inter-application communication and 

10 coordination. 

United States , Patent. Application Serial No , 
0 9/401, 4 19^ entitled "METHODS, SYSTEMS AND COMPUTER 
PROGRAM PRODUCTS FOR AUTOMATED MOVEMENT OF IP ADDRESSES 
WITHIN A CLUSTER" filed September 22, 1999, the 

15 disclosure of which is incorporated herein by reference 

as if set forth fully herein, describes dynamic virtual 
IP addresses (VIPA) and their use. As described in the 
'419 application, a dynamic VIPA may be automatically 
moved from protocol stack to protocol stack in a 

20 predefined manner to overcome failures of a particular 

protocol stack (i.e. VIPA takeover) . Such a predefined 
movement may provide a predefined backup protocol stack 
for a particular VIPA. VIPA takeover was made available 
by International Business Machines Corporation (IBM) , 

25 Armonk, NY, in System/390 V2R8 which had a general 

availability date of September, 1999. 

In addition to failure scenarios, scalability and 
load balancing are also issues which have received 
considerable attention in light of the expansion of the 

30 Internet. For example, it may be desirable to have 

multiple servers servicing customers. The workload of 
such servers may be balanced by providing a single 
network visible IP address which is mapped to multiple 
servers . 
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Such a mapping process may be achieved by, for 
example, network address translation (NAT) facilities, 
dispatcher systems and IBM's Dynamic Name Server/Workload 
Management DNS/WLM systems. These various mechanisms for 
5 allowing multiple servers to share a single IP address 

are illustrated in Figures 1 through 3. 

Figure 1 illustrates a conventional network address 
translation system as described above. In the system of 
Figure 1, a client 10 communicates over a network 12 to a 

10 network address translation system 14, The network 

address translation system receives the communications 
from the client 10 and converts the communications from 
the addressing scheme of the network 12 to the addressing 
scheme of the network 12 ■ and sends the messages to the 

15 servers 16. A server 16 may be selected from multiple 

servers 16 at connect time and may be on any host, one or 
more hops away. All inbound and outbound traffic flows 
through the NAT system 14 . 

Figure 2 illustrates a conventional DNS/WLM system 

2 0 as described above. As mentioned above, the server 16 is 

selected at name resolution time when the client 10 
resolves the name for the destination server from DNS/WLM 
system 17 which is connected to the servers 16 through 
the coupling facility 19. As described above, the 

25 DNS/WLM system of Figure 2 relies on the client 10 

adhering to the zero time to live. 

Figure 3 illustrates a conventional dispatcher 
system. As seen in Figure 3, the client 10 communicates 
over the network 12 with a dispatcher system 18 to 

30 establish a connection. The dispatcher routes inbound 

packets to the servers 16 and outbound packets are sent 
over network 12 ' but may flow over any available path to 
the client 10. The servers 16 are typically on a 
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directly connected network to the dispatcher 18 and a 
server 16 is selected at connect time. 

Such a dispatcher system is illustrated by the 
Interactive Network Dispatcher function of the IBM 2216 
5 and AIX platforms. In these systems, the same IP address 

that the Network Dispatcher node 18 advertises to the 
routing network 12 is activated on server nodes 16 as 
loopback addresses. The node performing the distribution 
function connects to the endpoint stack via a single hop 

10 connection because normal routing protocols typically 

cannot be used to get a connection request from the 
endpoint to the distributing node if the endpoint uses 
the same IP address as the distributing node advertises. 
Network Dispatcher uses an application on the server to 

15 query a workload management function (such as WLM of 

System/390), and collects this information at intervals, 
e.gr. 3 0 seconds or so. Applications running on the 
Network Dispatcher node can also issue "null" queries to 
selected application server instances as a means of 

20 determining server instance health. 

In addition to the above described systems, Cisco 
Systems offers a Multi-Node Load Balancing function on 
certain of its routers that perform the distribution 
function. Such operations appear similar to those of the 

25 IBM 2216. 

Finally, in addition to the system described above, 
AceDirector from Alteon provides a virtual IP address and 
performs network address translation to a real address of 
a selected server application. AceDirector appears to 

3 0 observe connection request turnaround times and rejection 

as a mechanism for determining server load capabilities. 

Summary of the Invention 
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Methods, systems and computer program products 
according to embodiments of the present invention provide 
communications with a plurality of application instances 
executing on a cluster of data processing systems having 
5 a plurality of communication protocol stacks associated 

therewith utilizing a single Internet Protocol (IP) 
address. A first of the plurality of communication 
protocol stacks is established as a routing communication 
protocol stack associated with the single IP address. 

10 Ones of the plurality of communication protocol stacks 

which are associated with the single IP address are 
defined as candidate target protocol stacks and an 
identification of candidate target protocol stacks and 
the routing communication protocol stack is distributed 

15 to the communication protocol stacks. The routing 

communication protocol stack is notified when an instance 
of the plurality of application instances associated with 
a candidate target communication protocol stack listens 
to a port of the single IP address to establish a current 

20 actual target stack. A request to establish a connection 

to the single IP address and the port of the single IP 
address is received and a routing table entry 
corresponding to the current actual target stack is 
created to provide a routing path associated with the IP 

2 5 address and the port from the routing communication 

protocol stack to the current actual target stack. 
Communications to the port of the IP address received by 
the routing communication protocol stack are routed based 
on the routing table. 

30 In further embodiments of the present invention, all 

of the plurality of communication protocol stacks of the 
cluster of data processing systems are defined as 
associated with the single IP address. Alternatively, 
enumerated ones of the plurality of communication 
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protocol stacks of the cluster of data processing systems 
may be defined as associated with the single IP address. 

In still further embodiments of the present 
invention, a first of the plurality of communication 
5 protocol stacks is established as a routing communication 

protocol stack associated with the single IP address for 
routing communications associated with at least one 
specified port associated with the IP address. Ones of 
the plurality of communication protocol stacks which are 

10 associated with the at least one specified port 

associated with the IP address are defined as candidate 
target communication protocol stacks and an 
identification of the candidate target protocol stacks 
and the routing communication protocol stack distributed 

15 to the plurality of communication protocol stacks. The 

routing communication protocol stack is notified when an 
instance of the plurality of application instances 
associated with a candidate target communication protocol 
stack listens to the at least one port of the single IP 

2 0 address. 

In such embodiments, the at least one port may be a 
plurality of ports identified in a port list associated 
with the single IP address. Furthermore, the least one 
port may be all ports associated with the single IP 

2 5 address. 

In additional embodiments, the first communication 
protocol stack is notified that the instance of the 
plurality of application instances associated with a 
candidate target communication protocol stack has 

3 0 terminated listening to the port of the single IP 

address. In such a case, the routing table entry 
corresponding to the candidate target communication 
protocol stack may be removed so as to remove the routing 
path associated with the IP address, the port and the 
35 candidate target communication protocol stack. Such 
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notification may be provided by sending a termination 
message through a cross coupling facility of the cluster 
of data processing systems. 

In still further embodiments of the present 
5 invention, the routing communication protocol stack is 

established and the plurality of communication protocol 
stacks defined by incorporating a VIPADISTribute 
statement in a VIPADynamic definition block associated 
with the first communication protocol stack. The 

10 VIPADISTribute statement defines a IP address as a 

dynamic routable virtual IP address (VIPA) , identifies 
ports associated with the VIPA which are routable, and 
identifies communication protocols stacks associated with 
the VIPA. In such embodiments, the distribution of an 

15 identification of protocol stacks which are associated 

with the single IP address and an identification of the 
first of the plurality of communication protocol stacks 
may be accomplished by broadcasting a list including the 
definitions of the VIPADISTRibute statement. 

20 In still further embodiments of the present 

invention, the routing communication protocol stack is 
notified that a connection utilizing the single IP 
address and the port of the singe IP address has 
terminated. The routing table entry corresponding to the 

2 5 connection to the candidate target communication protocol 

stack associated with the connection is then removed so 
as to remove the routing path associated with the IP 
address, the port and the second communication protocol 
stack . 

3 0 Furthermore, when a connection request is received 

by the routing communication protocol stack, one of the 
communication protocol stacks identified as having an 
application instance bound to the single IP address and 
listening to the port associated with the request is 
3 5 selected. The routing path may then be incorporated in 
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the routing table for the selected communication protocol 
stack . 

In further embodiments of the present invention, 
systems, methods and computer program products are 
5 provided for communicating with a plurality of 

application instances executing on a cluster of data 
processing systems having a plurality of communication 
protocol stacks associated therewith utilizing a single 
IP address may be provided by a routing communication 

10 protocol stack configured to receive communications to 

the single IP address and to forward to the received 
communications to a selected communication protocol stack 
from the plurality of communication protocol stacks. A 
destination port table associated with the routing 

15 communication protocol stack which identifies 

communication protocol stacks having application 
instances bound to the single IP address and listening to 
a predefined port of the single IP address. A current 
routing table associated with the routing communication 

2 0 protocol stack which identifies routing paths from the 

routing communication protocol stack to a communication 
protocol stack associated with a connection utilizing the 
single IP address and the predefined port . 

In further embodiments, the routing communication 
25 protocol stack is further configured to build the 

destination port table based on status messages received 
from communication protocol stacks of the plurality of 
communication protocol stacks having application 
instances bound to the single IP address and listening to 

3 0 a predefined port of the single IP address in response to 

distribution by the routing communication protocol stack 
of an identification of the single IP address and the 
predefined port as a routable IP address. Furthermore, 
the routing communication protocol stack may be further 
3 5 configured to incorporate into the current routing table 
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routing paths associated with new connection messages 
received by the routing communication protocol stack from 
communication protocol stacks which initiate connections 
utilizing the single IP address and the predefined port 
5 as a source address. 

In yet additional embodiments of the present 
invention, the routing communication protocol stack is 
further configured to receive requests for connections to 
the single IP address and the predefined port, select 

10 communication protocol stacks for the connections from 

the destination port table and update the current routing 
table with path information associated with the 
connections and the selected communication protocol 
stacks. The routing communication protocol stack may 

15 also be further configured to receive connection 

termination messages from communication protocol stacks 
which detect termination of connections utilizing the 
single IP address and predefined port and to update the 
current routing table to remove routing paths associated 

20 with the terminated connections. 

The predefined port may be a plurality of predefined 
ports identified in a port list associated with the 
single IP address or the predefined port may be all ports 
associated with the single IP address. 

25 As will further be appreciated by those of skill in 

the art, the present invention may be embodied as 
methods, apparatus/systems and/or computer program 
products. 

3 0 Brief Description of the Drawings 

Figure 1 is block diagram of a conventional network 
address translation system; 

Figure 2 is block diagram of a conventional DNS/WLM 
system; . 
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Figure 3 is block diagram of a conventional 

dispatcher system; 

Figure 4 is block diagram of a cluster of data 

processing systems incorporating embodiments of the 
5 present inventions- 

Figure 5 is a flowchart illustrating operations for 

initialization of a routing protocol stack incorporating 

distributable VIPAs according to embodiments of the 

present invention ; 
10 Figure 6 is a flowchart illustrating operations of a 

server protocol stack according to embodiments of the 

present inventions- 
Figure 7 is a flowchart illustrating operations for 

a incoming communications to the routing protocol stack 
15 according to embodiments of the present inventions- 

Figure 8 is a flowchart illustrating operations of a 

routing protocol stack receiving communications from 

another protocol stack according to embodiments of the 

present invention; ^ 
20 Figure 9 is a flowchart illustrating operations of 

protocol stacks during failure of a routing protocol 

stack according to embodiments of the present invention; 
Figure 10 is a flowchart illustrating operations of 

protocol stacks according to embodiments of the present 
25 invention incorporating moveable VIPAs for recovery of a 

failed routing protocol stack; 

Figure 11 is a flowchart illustrating operations of 

a communication protocol stack which owns a moveable 

VI PA ; and 

30 Figure 12 is a flowchart illustrating operations of 

a communications protocol stack in response to loss of 
ownership of a moveable VIPA. 



Detailed Description of the Invention 

RSW9-2 000-0 082-US1 -14- 



I? 



The present invention now will be described more 
fully hereinafter with reference to the accompanying 
drawings, in which preferred embodiments of the invention 
are shown. This invention may, however, be embodied in 
5 many different forms and should not be construed as 

limited to the embodiments set forth herein; rather, 
these embodiments are provided so that this disclosure 
will be thorough and complete, and will fully convey the 
scope of the invention to those skilled in the art. Like 

10 numbers refer to like elements throughout. 

As will be appreciated by those of skill in the 
art, the present invention can take the form of an 
entirely hardware embodiment, an entirely software 
(including firmware, resident software, micro-code, etc.) 

15 embodiment, or an embodiment containing both software and 

hardware aspects. Furthermore, the present invention can 
take the form of a computer program product on a 
computer-usable or computer- readable storage medium 
having computer-usable or computer-readable program code 

2 0 means embodied in the medium for use by or in connection 

with an instruction execution system. In the context of 
this document, a computer-usable or computer- readable 
medium can be any means that can contain, store, 
communicate, propagate, or transport the program for use 
25 by or in connection with the instruction execution 

system, apparatus, or device. 

The computer-usable or computer- readable medium can 
be, for example, but is not limited to, an electronic, 
magnetic , optical , electromagnetic , infrared, or 

3 0 semiconductor system, apparatus, device, or propagation 

medium. More specific examples (a nonexhaust ive list) of 
the computer-readable medium would include the following: 
an electrical connection having one or more wires, a 
removable computer diskette, a random access memory 
3 5 (RAM) , a read-only memory (ROM) , an erasable programmable 
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read-only memory (EPROM or Flash memory) , an optical 
fiber, and a portable compact disc read-only memory (CD- 
ROM) . Note that the computer-usable or computer-readable 
medium could even be paper or another suitable medium 
5 upon which the program is printed, as the program can be 

electronically captured, via, for instance, optical 
scanning of the paper or other medium, then compiled, 
interpreted, or otherwise processed in a suitable manner 
if necessary, and then stored in a computer memory. 

10 The present invention can be embodied as systems, 

methods, or computer program products which allow for a 
single IP address being associated with a plurality of 
communication protocol stacks in a cluster of data 
processing systems by providing a routing protocol stack 

15 which associates a Virtual IP Address (VIPA) and port 

with other communication protocol stacks in the cluster 
and routes communications to the VIPA and port to the 
appropriate communication protocol stack. VIPAs capable 
of being shared by a number of communication protocol 

20 stacks are referred to herein as "dynamic routable VIPAs" 

(DVIPA) . While the present invention is described with 
reference to a specific embodiment in a System/390 
Sysplex, as will be appreciated by those of skill in the 
art, the present invention may be utilized in other 

25 - systems where clusters of computers utilize virtual 

addresses by associating an application or application 
group rather than a particular communications adapter 
with the addresses. Thus, the present invention should 
not be construed as limited to the particular exemplary 

3 0 embodiment described herein. 

A cluster of data processing systems is illustrated 
in Figure 4 as a cluster nodes in Sysplex 10. As seen in 
Figure 4, several data processing systems 20, 24, 28, 32 
and 36 are interconnected in a Sysplex 10. The data 

35 processing systems 20, 24, 28, 32 and 36 illustrated in 
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Figure 4 may be operating system images, such as MVS 
images, executing on one or more computer systems. While 
the present invention will be described primarily with 
respect to the MVS operating system executing in a 
5 System/390 environment, the data processing systems 20, 

24, 28, 3 2 and 36 may be mainframe computers, mid- range 
computers, servers or other systems capable of supporting 
dynamic routable Virtual IP Addresses and which are 
capable of error recovery as described herein. 

10 As is further illustrated in Figure 4, the data 

processing systems 20, 24, 28, 32 and 36 have associated 
with them communication protocol stacks 22, 26, 30, 34 
and 38, which may be TCP/IP stacks. The communication 
protocol stacks 22, 26, 30, 34 and 38 have been modified 

15 to incorporate a VIPA distribution function 23 as 

described herein for providing dynamic routable VIPAs so 
as to provide a single IP address for multiple 
communication protocol stacks. 

While each of the communication protocol stacks 22, 

20 26, 30, 34 and 38 illustrated in Figure 4 incorporate the 

VIPA distribution function 23, not all communication 
protocol stacks in a Sysplex need incorporate the VIPA 
distribution function 23. Thus, the present invention 
may be carried out on any system where two or more 

25 communication protocol stacks in a cluster of data 

processing systems support dynamic routable VIPAs. If a 
communication protocol stack does not support dynamic 
routable VIPA, then the dynamic routable VIPA messages 
according to the present invention would be ignored by 

3 0 the communication protocol stack. Thus, the present 

invention provides backward compatibility with existing 
communication protocol stacks. 

As is further seen in Figure 4, the communication 
protocol stacks 22, 26, 30, 34 and 38 may communicate 
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with each other through a coupling facility 40 of the 
Sysplex 10, for example, utilizing XCF messaging. 
Furthermore, the communication protocol stacks 22 and 3 8 
may communicate with an external network 44 such as the 
5 Internet, an intranet, a Local Area Network (LAN) or Wide 

Area Network (WAN) utilizing the Enterprise System 
Connectivity (ESCON) 42. Thus, a client 46 may utilize 
network 44 to communicate with an application executing 
on an MVS image in Sysplex 10 through the communication 

10 protocol stacks 22 and 38 which may function as routing 

protocol stacks as described herein. 

As is further illustrated in Figure 4, as an example 
of utilization of the present invention and for 
illustration purposes, data processing system 20 has 

15 associated with it communication protocol stack 22 which 

is associated with MVS image MVS 1 which has application 
APP A executing on MVS image MVS 1 and utilizing 
communication protocol stack 22 to allow access to, for 
example, client 46 through network 44 . Similarly, data 

20 processing system 24 has associated with it communication 

protocol stack 26 which is associated with MVS image MVS 
2 which has a second instance of application APP A and an 
instance of application APP B executing on MVS image MVS 

2 which may utilize communication protocol stack 26 for 
25 communications. Data processing system 28 has associated 

with it communication protocol stack 30 which is 
associated with MVS image MVS 3 which has a second 
instance of application APP B executing on MVS image MVS 

3 which may utilize communication protocol stack 30 for 
30 communications. Data processing system 32 has associated 

with it communication protocol stack 34 which is 
associated with MVS image MVS 4 which has a third 
instance of application APP A executing on MVS image MVS 
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4 which may utilize communication protocol stack 34 for 
communications. Finally, data processing system 36 has 
associated with it communication protocol stack 38 which 
is associated with MVS image MVS 5 which has a third 

5 instance of application APP B executing on MVS image MVS 

5 which may utilize communication protocol stack 38 for 
communications . 

Utilizing the above described system configuration 
as an example, the VIPA distribution function 23 will now 

10 be described. The VIPA distribution function 23 allows 

for protocol stacks which are defined as supporting 
DVIPAs to share the DVIPA and communicate with network 44 
through a routing protocol stack such that all protocol 
stacks having a server application which is associated 

15 with the DVIPA will appear to the network 44 as a single 

IP address. Such dynamically routable VIPAs may be 
provided by designating a protocol stack, such as 
protocol stack 22, as a routing protocol stack, notifying 
other protocol stacks of the routing protocol stack and 

20 having other protocol stacks notify the routing protocol 

stack when an application which binds to the DVIPA is 
started. Because communications to the DVIPA are routed 
through the routing protocol stack, the routing protocol 
stack may provide work load balancing by distributing 

25 connections to the other protocol stacks on MVS images 

executing server applications which bind to the DVIPA to 
balance workload. Furthermore, in particular embodiments 
of the present invention, scalability and availability 
may be provided by allowing all protocol stacks for MVS 

3 0 images which execute applications which bind to the DVIPA 

to have communications routed through the routing 
protocol stack without user intervention to establish the 
routing path. 
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Further aspects of the VIPA distribution function 23 
according to embodiments of the present invention allow 
automated movement of a routing protocol function to a 
backup stack. Another aspect of the VIPA distribution 
5 function 23 allows recovery of a failed routing stack 

without disruption to connections through the backup 
stack . 

The communication protocol stacks 22, 26, 30, 34 and 
38 may be configured as to which stacks are routing 
10 stacks, backup routing stacks and server stacks. 

Different DVIPAs may have different sets of backup 
stacks, possibly overlapping. The definition of backup 
stacks may be the same as that for the VIPA takeover 
function described in UnitedLStates Patent, Application 




15 Serial No. 09/401 , 419 , ^entitled "METHODS, SYSTEMS AND 

COMPUTER PROGRAM PRODUCTS FOR AUTOMATED MOVEMENT OF IP 
ADDRESSES WITHIN A CLUSTER" which is incorporated herein 
by reference as if set forth fully herein. 

In providing for DVIPAs, up to five or more aspects 

20 of DVIPA operation may be addressed: 1) initialization 

and definition of DVIPAs and the affected protocol 
stacks; 2) incoming communications from network 44 to the 
DVIPA; 3) connections originated by a protocol stack 
(i.e. outgoing to network 44); 4)failure of a routing 

2 5 stack; and 5) recovery of a routing stack. 

Turning now to the first of these aspects, for the 
present example, application APP A is associated with 
DVIPA VAl which may be associated with the respective 
first, second and third instances of APP A; and 

30 application APP B likewise has DVIPA VBl associated with 

the respective first, second and third instances of APP 
B. 

Configuration of a dynamic routable VIPA may be 
provided by a new definition block established by a 
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system administrator for each routing communication 
protocol stack 22 and 38. The new definition block 
defines dynamic routable VIPAs for which a communication 
protocol stack operates as the primary communication 
5 protocol stack. Backup protocol stacks may be defined as 

described of the VIPA takeover procedure. Thus, a 
definition block " VIPADynamic " may be defined as 
VIPADynamic 

Dynamic Routable VIPA definitions ... 
10 ENDVIPADynamic 

The definitions within the VIPADynamic block for a 
protocol stack supporting moveable VIPAs are: 
VIPADEFine MOVEable IMMEDiate netMask ipaddr ... 
where the netMask is used to determine the network prefix 

15 to be advertised to routing daemons for OSPF or RIP and 

ipaddr is the IP address of the DVIPA. Both network 
prefix (sometimes known as subnet address) and the mask 
will be advertised to the routing daemon. All of the 
VIPAs in a single VIPADEFine statement must belong to the 

2 0 same subnet, network, or supernet, as determined by the 

network class and address mask. The MOVEable IMMEDiate 
parameters define the VIPAs as moveable VIPAs which may 
be transferred from one communication protocol stack to 
another. As will be appreciated by those of skill in the 

25 art in light of the present disclosure, while the 

MOVEable IMMEDiate parameters are expressly defined in 
the above definition statements, these or other 
parameters may be the default parameters which are 
provided unless specified otherwise. Thus, the 

30 parameters need not be expressly called out in all 

instances , 

The definitions within the VIPADynamic block for 
backup are : 

VIPABackup rank ipaddr ... 
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where the rank is a number between 1 and 2 54 used to 
determine relative order within the backup chain (s) for 
the associated dynamic routable VIPA(s) . A communication 
protocol stack with the higher rank will take over the 
5 dynamic VIPAs before a communication protocol stack with 

a lower rank. 

The definitions in the VIPADYNamic block for 
defining a VIPA as a dynamic routable VIPA are: 
VIPADISTribute ipaddr PORT portlist DESTIP ipaddrlist 

10 where ipaddr is a VIPA defined in the VIPADEFine, 

portlist is a list of ports for which the DVIPA will 
apply. If the PORT keyword is omitted, then all ports 
for the ipaddr will be considered as DVIPAs. The 
ipaddrlist is a list of protocol stacks which will be 

15 included as server stacks in routing communications 

directed to the DVIPA. The IP addresses in the 
ipaddrlist may be XCF addresses of the protocol stacks or 
may be designated "ALL." If "ALL" is designated, then 
all stacks in the Sysplex are candidates for 

20 distribution. This may include future stacks which are 

not active when the routing stack is initialized. Thus, 
if ALL is specified, a protocol stack may be added to the 
DVIPA without disruption of operations and without user 
intervention to redefine the stack in the VIPADynamic 

25 block. 

In addition to the above definitions, a range of IP 
addresses may be defined as DVIPAs utilizing the 
VIPARange definition. A VIPARange definition of the 
form: 

3 0 VIPARange MOVEable NONDISRUPTIVE netMASK ipAddr 

may designate all future VIPAs created in the range as 
moveable or dynamic routable VIPAs. The MOVEable 
NONDISRUPTIVE parameters allows future instance-specific 
dynamic VIPAs to participate as dynamic routable VIPAs 
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but does not affect dynamic VIPAs created under the range 
before the keyword DISTribute was added {e.g. via VARY 
OBEY) . 

In the first aspect, the communication protocol 
5 stacks 22 and 38, which are designated as routing 

protocol stacks as they have connections to the network 
44 and include VIPADISTribute statements in the 
VIPADynamic block, publish the distribution information 
through messages broadcast by the VIPA takeover function 

10 23 of each of the communication protocol stacks 22, 26, 

30, 34 and 38 to the other communication protocol stacks 
22, 26, 30, 34 and 38. At initialization or profile 
changes, the communication protocol stacks 22, 26, 30, 34 
and 38 communicate to all partner communication protocol 

15 stacks the complete list of dynamic routable VIPAs, their 

associated ipAddrList and portlist and the primary and 
backup definitions for the communication protocol stack. 

When a communication protocol stack 22, 26, 30, 34 
and 38 receives the DVIPA information it notes if it is 

20 identified as a candidate target protocol stack or as a 

backup stack. If the protocol stack is a candidate target 
stack, it monitors its applications and sends a message 
to the defined routing stack when an application instance 
is bound to the DVIPA and listens on a defined port. If 

2 5 the protocol stack is a backup stack it stores the DVIPA 

information for use in the event of failure of the 
primary routing stack. 

Returning to the example of Figure 4, for MVSl to 
MVS5 the VIPADEFine statements may be: 

3 0 MVS1:VIPADEFine MOVEable IMMEDiate DVA1 

VIPADISTribute DVA1 PORT 60 DESTIP XCF1, XCF2, XCF4 
MVS5:VIPADEFine MOVEable IMMEDiate DVB1 

VIPADISTribute DVB1 PORT 60 DESTIP ALL 
VIPADISTribute DVA1 PORT 60 DESTIP XCF2, XCF3, XCF4 
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For purposes of illustration the respective address masks 
have been omitted because they are only significant to 
the routing daemons. In the above illustration, XCFl is 
an XCF address of the TCP/IP stack on MVSl, XCF2 is an 
5 XCF address of the TCP/IP stack on MVS2 and XCF3 is an 

XCF address of the TCP/IP stack on MVS4 . Note that, for 
purposes of the present example, definitions for MVS2, 
MVS3 , and MVS4 are not specified. Such may be the case 
because the protocol stacks for these MVS images are 

10 candidate target protocol stacks and are not identified 

as routing protocol stacks and, therefore, receive their 
dynamic routable VIPA definitions from the routing 
protocol stacks. As is further illustrated, the backup 
routing communication protocol stack may have a separate 

15 VIPADISTribute definition for a DVIPA than the primary 

routing communication protocol stack. As described in 
more detail below, in such a case the explicit definition 
of the VIPADISTribute statement for the backup routing, 
communication protocol stack in the event of failure of 

20 the primary routing stack. Additional VIPA definitions 

may also be provided, however, in the interests of 
clarity, such definitions have been omitted. 

The VIPABackup statements for MVSl and MVS5 of 
Figure 4 may be : 

2 5 MVS1 : VIPABackup 30 DVB1 

MVS5: VIPABackup 10 DVA1 

with the above scenario in mind, embodiments of the 
present invention will now be described with reference to 
Figures 5 through 12 which are flowchart illustrations of 
3 0 operations of protocol stacks incorporating embodiments 

of the present invention. It will be understood that each 
block of the flowchart illustrations and/or block 
diagrams, and combinations of blocks in the flowchart 
illustrations and/or block diagrams, can be implemented 
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by computer program instructions. These program 
instructions may be provided to a processor to produce a 
machine, such that the instructions which execute on the 
processor create means for implementing the functions 
5 specified in the flowchart and/or block diagram block or 

blocks. The computer program instructions may be 
executed by a processor to cause a series of operational 
steps to be performed by the processor to produce a 
computer implemented process such that the instructions 

10 which execute on the processor provide steps for 

implementing the functions specified in the flowchart 
and/or block diagram block or blocks . 

Accordingly, blocks of the flowchart illustrations 
and/or block diagrams support combinations of means for 

15 performing the specified functions, combinations of steps 

for performing the specified functions and program 
instruction means for performing the specified functions. 
It will also be understood that each block of the 
flowchart illustrations and/or block diagrams, and 

20 combinations of blocks in the flowchart illustrations 

and/or block diagrams, can be implemented by special 
purpose hardware -based systems which perform the 
specified functions or steps, or combinations of special 
purpose hardware and computer instructions. 

25 Figure 5 illustrates operations of a routing 

communication protocol stack, such as the protocol stacks 
22 and 38 in Figure 4 in the present example. As seen in 
Figure 5, the dynamic routable VI PA is defined as 
described above to include the candidate target stack XCF 

30 IP addresses and the ports for the DVIPA (block 100) . In 

the present example, the protocol stack 22 has DVIPA DVAl 
identified as the dynamic routable VIPA, port 60 is 
routable and the candidate target stacks are 
communication protocol stacks corresponding to XCF 
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addresses XCFl, XCF2 , and XCF4 . The protocol stack 38 
has DVIPA DVBl identified as the dynamic routable VIPA, 
port 60 is routable and the candidate target stacks are 
specified by the "ALL" value and may be any stack in the 
cluster . 

The routing communication protocol stack distributes 
the list of DVIPAs, ports and candidate target stacks to 
each of the stacks in the cluster (block 102) . Such a 
distribution may be carried out by, for example, 
broadcasting the information as part of a VIPA_list as is 
utilized in VIPA takeover. In the present example, 
communication protocol stacks 22 and 38 would distribute 
their information to the other communication protocol 
stacks 22, 26, 30, 34 and 38. The routing communication 
protocol stacks 22 and 38 also advertise their respective 
DVIPAs as IP addresses through the routing protocol 
utilized to communicate with the network 44 (block 104) . 
Alternatively, as described below, with reference to 
Figures 11 and 12, ownership of the DVIPAs for 
communications on the network 44 may be established 
through the IP Assist function of Queued Direct I/O for 
OSA Express adapters. 

The routing communication protocol stacks also wait 
for messages from the other communication protocol stacks 
which identify applications which are bound to their 
DVIPAs and listen on an identified port (block 106) . As 
the messages are received, the routing communication 
protocol stacks build a Destination Port Table (DPT) 
which identifies those stacks having instances of 
applications bound to the DVIPA and listening on an 
identified port (block 108) . Thus, the routing 
communication protocol stacks, such as the communication 
protocol stacks 22 and 38, are notified of which 
communication protocol stacks have applications bound to 
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the DVIPA and which are available to distribute 
connections to the DVIPA so as to balance workload 
between the applications . 

Figure 6 illustrates operations carried out by a 
5 VIPA distribution function 23 of a. communication protocol 

stack upon receiving a message from another communication 
protocol stack. As seen in Figure 6, when a protocol 
stack receives a message (block 120) , the protocol stack 
determines if the message contains a VIPA list (block 

10 122). If not, then operations of the VIPA distribution 

function 23 terminate. If DVIPA information is present 
in the message, then the VIPA distribution function 23 
determines if the communication protocol stack is 
identified as a candidate target stack for the DVIPA 

15 (block 124) . If the communication protocol stack is a 

candidate target stack, either as a result of being 
expressly enumerated in a list or because the "ALL" 
parameter is specified for the DVIPA, then the protocol 
stack adds the DVIPA as a non-advertised or internal VIPA 

20 address (i.e. not advertised to the routing protocol), if 

it is not already active as such, which may be utilized 
by the communication protocol stack in a manner similar 
to a loopback address (block 126) . 

The communication protocol stack also monitors the 

25 addresses and ports associated with application instances 

utilizing the protocol stack and, if an application 
utilizing the protocol stack is bound or binds to the 
DVIPA and listens on a port identified in the VIPA list 
as a DVIPA port (block 128) , the protocol stack sends a 

3 0 message to the routing communication protocol stack 

associated with the DVIPA to notify the routing 
communication protocol stack that communications may be 
routed to the application through the candidate target 
stack (block 130) . Such candidate target protocol stacks 
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which have applications bound to the DVIPA and listening 
on a port associated with the DVIPA may be referred to as 
a "current actual target" and, as described above, are 
identified in the DPT of the routing communication 
5 protocol stack as available for receiving connections. A 

message may also be sent if an application instance bound 
to a DVIPA and listening to a port identified in the VIPA 
list terminates so that the VIPA distribution function 23 
of the routing communication protocol stack may maintain 

10 an up-to-date DPT. While the sending of a message to 

notify the routing communication protocol stack of the 
existence of an application bound to the DVIPA and 
listening to a port of the DVIPA is illustrated in Figure 
6 as responsive to receiving a message from the routing 

15 communication protocol stack, as will be appreciated by 

those of skill in the art, once the DVIPA is active, such 
messages could be sent any time the candidate target 
stack detects that an application is bound to the DVIPA 
and listening on a DVIPA port. 

2 0 Furthermore, the candidate target protocol stack may 

also determine if there are any active connections to the 
DVIPA (block 131) . If so, then a connection message may 
be sent to the routing protocol stack (block 133) to 
notify it of the existence of the connection. In such a 

2 5 manner the routing protocol stack may incorporate the 

connection in its current routing table as described 
herein. Such a connection message may allow for movement 
of connections between routing protocol stacks, for 
example, to recover from a failure of a routing protocol 

30 stack. 

Irrespective of whether a communication protocol 
stack is a candidate target stack or a current actual 
target stack, a communication protocol stack may be a 
backup for a routing communication protocol stack. Thus, 
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as seen at block 132, the communication protocol stack 
may determine if it is a backup for the routing 
communication protocol stack associated with the VIPA 
list. The backup routing communication protocol stack 
5 may also determine it if has its own VIPADISTribute 

statement such that it would override the VIPA list 
information (block 135) . If so, then the communication 
protocol stack need not maintain the VIPA list 
information as it will use its own information, 

10 Otherwise, the backup communication protocol stack 

maintains the information from the VIPA list so as to 
perform backup operations in the event of failure of the 
primary routing stack (block 134) . Thus, the backup 
protocol stack may utilize a different distribution 

15 pattern than the primary protocol stack. Such 

differences may allow for reducing the disruption of a 
failed stack until the failed stack may be restored by, 
for example, adding candidate target stacks that are only 
utilized when a failure of the routing stack occurs. 

2 0 In the present example illustrated in Figure 4, the 

protocol stack 22 of MVSl would broadcast a VIPA list 
(DVIPA_list_l) identifying MVSl as the primary routing 
communication protocol stack, DVAl as a dynamic routable 
VIPA with port 60 as an associated port and the 

25 communication protocol stacks 22, 26 and 34 as candidate 

target communication protocol stacks. Additionally, the 
protocol stack 38 of MVS5 would broadcast a VIPA list 
(DVIPA_list_2 ) identifying MVSl as the primary routing 
communication protocol stack, DVBl as a dynamic routable 

30 VIPA with port 60 as an associated port and all of the 

communication protocol stacks 22, 2 6 30, 34 and 3 8 as 
candidate target communication protocol stacks. Also, 
the communication protocol stack 22 would be identified 
as a backup to the communication protocol stack 3 8 and 
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the communication protocol stack 38 would be identified 
as a backup to the communication protocol stack 22. The 
communication protocol stack 22 would retain the 
information in the distributed VIPA list for DVB2 as the 
5 communication protocol stack 22 does not have a 

VIPADISTribute statement for DVB2 . However, the 
communication protocol stack 3 8 need not retain the 
received VIPA list for DVAl as it has its own, explicit, 
VIPADISTribute statement for DVAl. 

10 When, for example, communication protocol stack 26 

receives DVIPA_list_l , it examines the list and 
determines that it is identified as a candidate target 
stack. Thus, the VIPA distribution function 23 of 
communication protocol stack 26 adds the DVIPA DVAl as a 

15 non-routable VIPA and determines if an application is 

executing which is bound to DVAl and listening to port 
60. For purposes of the present example, APP A is bound 
to DVAl and listening to port 60 so the communication 
protocol stack 26 sends a SRVSTAT message to 

2 0 communication protocol stack 22 identifying itself as a 

current actual target. The VIPA distribution function 23 
of the communication protocol stack 22 incorporates the 
XCF address of the communication protocol stack 22 into 
its DPT. Messages to port 60 of the DVIPA may then be 
25 routed to the communication protocol stack 26, Because 

no connections exist at this time a NEWCONN message is 
not sent . 

When the communication protocol stack 30 receives 
DVIPA_list_l , it examines the list and is not identified 

3 0 as a candidate target stack or as a backup to the 

communication protocol stack 22 and may disregard the 
list. When the communication protocol stack 38 receives 
DVIPA_list_l , it examines the list and is not identified 
as a candidate target stack but is identified as a backup 
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to the communication protocol stack 22. Thus, the 
communication protocol stack 38 stores the list for use 
in error recovery. 

When any of the communication protocol stacks 22, 
5 26, 30, 34 and 38 receive the DVIPA_list_2 , then note 

that the "ALL" parameter is identified and add the DVIPA 
DVBl as a non-routable VIPA. These communication 
protocol stacks 22, 26, 30, 34 and 38 the monitor for 
applications bound DVBl and listening on port 60 to 

10 determines if an application is executing which is bound 

to DVAl and listening to port 60. If and when such an 
application binds to DVB2 and listens on port 6 0 a 
SRVSTAT message is sent to the communication protocol 
stack 38 to identify the candidate target stack as a 

15 current actual target as described above. Furthermore, 

if a communication protocol stack is subsequently 
activated, it too will identify DVBl as a DVIPA and add 
DVBl as a non-routable VIPA. 

Figure 7 illustrates operations of a routing 

20 communication protocol stack when a communication is 

received from the network 44. As is seen in Figure 7, 
the VIPA distribution function 23 of the communication 
protocol stack determines if the communication is to a 
DVIPA associated with the stack (block 140) by, for 

25 example, examining the IP address and port of the 

communication and comparing that with those of the DVIPAs 
for the protocol stack. If the communication is not to a 
DVIPA of the protocol stack, then operations of the VIPA 
distribution function 23 may terminate with respect to 

3 0 the communication. 

If the communication is to a DVIPA of the protocol 
stack, then the VIPA distribution function 23 determines 
if the communication is a SYN to establish a connection 
to the DVIPA (block 142) . If so, then the VIPA 
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distribution function 23 may select a current actual 
target for the connection (i.e. a communication protocol 
stack with an application bound to the DVIPA and 
listening to the port specified by the 
5 communication) (block 144) . Such a selection may, for 

example, be based on predefined criteria, utilizing a 
predefined selection pattern, such as round-robin, 
weighted round- robin or the like, or may be based on 
dynamic criteria, policies or combinations thereof. For 

10 example, the selection may be made to distribute workload 

between the candidate target stacks. Thus, a workload 
manger and/or a service policy agent may be consulted in 
selecting the candidate target stack. 

However the selection is made, the VIPA distribution 

15 function 23 updates a current routing table (CRT) which 

defines the path from the routing communication protocol 
stack to the selected current actual target (block 146) . 
Such an update may take the form of creating an entry 
incorporating the source IP address, DVIPA and port and 

20 the XCF address of the selected current actual target. 

The message is also forwarded to the selected current 
actual target using the XCF address of the current actual 
target (block 150) . 

Returning to block 142, if the communication is not 

25 a SYN message, then the VIPA distribution function 23 of 

the routing communication proto.col stack consults the CRT 
to route the communication and, if an appropriate 
destination communication protocol stack is found, routes 
the communication to the current actual target for the 

30 communication (block 152) . The communication is then 

forwarded to the current actual target specified by the 
CRT (block 150) . 

Figure 8 illustrates operations of the VIPA 
distribution function 23 of the routing communication 
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protocol stack when a message is received from another 
communication protocol stack. As is seen in Figure 8, 
the VIPA distribution function 23 determines the type of 
message received (block 160) . If the message is a 
5 SRVSTAT message, then, as described above, the 

application and communication protocol stack entries of 
the DPT are updated (block 166) by the VIPA distribution 
function 23. As described above, the SRVSTAT message may 
be sent by a communication protocol stack both when an 

10 application instance binds to the DVIPA and listens to an 

associated port and when the application instance 
terminates. Thus, the SRVSTAT message may be utilized by 
the VIPA distribution function 23 to maintain the DPT 
with up-to-date information as to the current actual 

15 targets available for connections (block 166) . 

Returning to block 160, the VIPA distribution 
function 23 may also determine if the message is a new 
connection message (NEWCONN) . Such a message may be 
generated if an application bound to a DVIPA utilizing a 

20 port in the VIPA list initiates a connection or, as 

described above, if a communication protocol stack 
receives a VIPA list with a DVIPA which already have 
applications using the DVIPA for connections, then the 
VIPA distribution function 23 of the communication 

25 protocol stack sends a NEWCONN message to the routing 

communication protocol stack to notify the routing 
communication protocol stack of the connection. If the 
message is a NEWCONN message, then the VIPA distribution 
function 23 incorporates the connection into the CRT 

30 (block 164) . Such an incorporation of the connection 

into the CRT may be carried out as described above for 
connections originated from network 44. 

A third type of message which may be received by the 
VIPA distribution function 23 is a connection termination 
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message (TERMCONN) . Such a message may be generated by a 
VIPA distribution function 23 when a connection 
terminates. When the connection terminates, the VIPA 
distribution function 23 of the communication protocol 
5 stack sends a TERMCONN message to the routing 

communication protocol stack to notify the routing 
communication protocol stack that the connection has 
ended and routing for the connection may be discontinued. 
Thus, if the message is a TERMCONN message (block 160) , 

10 then the VIPA distribution function 23 removes the 

connection from the CRT (block 162) . Such a removal of 
the connection from the CRT may be carried out by, for 
example, deleting or invalidating an entry in the CRT 
corresponding to the connection. 

15 Returning to the example illustrated in Figure 4, 

when a SYN message to port 6 0 of DVAl is received from 
network 44 by communication protocol stack 22, the VIPA 
distribution function 23 determines that the SYN is to a 
dynamic rentable VIPA for which it is the routing 

20 communication protocol stack, consults it DPT and 

optionally a workload management function (not shown) and 
selects a current actual target as a destination for the 
message. Thus, the VIPA distribution function 23 of the 
communication protocol stack 22 may select the 

25 communication protocol stack 26 as a destination. The 

communication protocol stack 22 creates an entry for the 
connection in its CRT and forwards the message to the 
communication protocol stack 26. Subsequent messages 
from the network 44 to port 6 0 of DVAl from the source IP 

3 0 address will also be routed to the communication protocol 

stack 2 6 using the CRT entry. 

An instance of APP A of the communication protocol 
stack 26 bound to DVAl and utilizing port 60 may also 
establish a connection over network 44 either directly or 
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through another protocol stack. When such occurs, the 
VIPA distribution function 23 of communication protocol 
stack 26 sends a NEWCONN message to the routing 
communication protocol stack 22 identifying the new 
5 connection. The VIPA distribution function 23 of 

communication protocol stack 22 receives the NEWCONN 
message and updates its CRT to route communications from 
the identified new connection to port 60 of DVAl to the 
communication protocol stack 26. Such an identification 

10 may be made by, for example, providing the source IP 

address of the other end of the connection, the DVIPA and 
port and the XCF address of the communication protocol 
stack 26 to the routing communication protocol stack 22. 
In any event, when either of the connections ends, 

15 the VIPA distribution function 23 of the communication 

protocol stack 2 6 sends a TERMCONN message to the VIPA 
distribution function 23 of the communication protocol 
stack 22. The VIPA distribution function 23 of the 
communication protocol stack 22 removes the entry from 

2 0 the CRT corresponding to the function and, thereby, 

terminates routing for the connection. 

Figures 9 and 10 illustrate operations of the VIPA 
distribution function 23 during failure of a routing 
communication protocol stack and during recovery of a 

25 routing communication protocol stack. As seen in Figure 

9, when a failure occurs, the other communication 
protocol stacks in the cluster of data processing systems 
are notified of the failure (block 200) . The 
communication protocol stack identified as the backup 

30 stack for the dynamic routable VIPA takes over routing 

functions for that DVIPA so as to become a backup routing 
communication protocol stack. In addition, the backup 
routing communication protocol stack may broadcast the 
DVIPA list that it will utilize in routing connections 
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for the DVIPA (block 201) . This list may be the list 
provided by the primary routing communication protocol 
stack or a list defined explicitly for the backup routing 
communication protocol stack. Alternatively, the list 
5 may need only be distributed in the instance where the 

backup routing communication protocol stack has an 
explicitly defined DVIPA list. 

As described above, because of the broadcast of 
information each of the communication protocol stacks is 

10 aware that it is a candidate target for a DVIPA and the . 

identity of the highest ranking backup routing 
communication protocol stack. Therefore, the 
communication protocol stacks with application instances 
bound to the DVIPA and listening on an associated port 

15 may send a SRVSTAT message and a NEWCONN message (s) for 

connections to the DVIPA for the communication protocol 
stack to the backup routing communication protocol stack 
(block 202) . The communication protocol stacks also 
associate the backup routing communication protocol stack 

20 with any connections utilizing the DVIPA so that 

subsequent messages for the DVIPA are sent to the backup 
routing communication protocol stack (block 204) . The 
backup routing communication protocol stack utilizes the 
SRVSTAT messages and its information from the appropriate 

25 VIPA list to build a new DPT for the DVIPA (block 206) . 

The backup routing communication protocol stack also 
receives NEWCONN messages from the server communication 
protocol stacks with existing DVIPA connections and 
constructs a CRT based on these messages (block 208) . The 

3 0 routing information from the constructed CRT is 

incorporated into the backup routing communication 
protocol stack's own CRT (block 210). The backup routing 
communication protocol stack may also send its own DVIPA 
messages to the other communication protocol stacks to 
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notify the other communication protocol stacks that it is 
performing the backup function (block 212) . Such 
messages may be sent to prevent other backup 
communication protocol stacks in a list of backups from 
5 taking over the DVIPA. Details on the transfer of a VIPA 

to a backup are provided in United States Patent 
Application Serial No. 09/401,419 described above. 
Furthermore, in particular embodiments, the issuance of 
the SRVSTAT or the NEWCONN messages may be in response to 

10 the DVIPA messages sent by the backup routing 

communication protocol stack. Thus, embodiments of the 
present invention are not limited to the sequence 
illustrated in Figures 9 and 10. Operations then 
continue with the backup routing communication protocol 

15 stack operating as the routing communication protocol 

stack described above. 

Turning to Figure 10, when the primary communication 
protocol stack recovers, it again broadcasts its VIPA 
list which is received by the other communication 

20 protocol stacks (block 300) . In response to receiving 

the VIPA list, the candidate target stacks send SRVSTAT 
messages to the recovered primary routing communication 
protocol stack (block 302) which identify the stacks 
which have application instances bound to the DVIPA and 

25 utilizing a port of the VIPA list. The recovered primary 

routing communication protocol stack also sends a DVIPA 
message to the backup communication protocol stack which 
receives the takeback message (block 304) and generates a 
NEWCONN message for all the connections which are routed 

3 0 through the backup communication protocol stack (block 

306) . The NEWCONN message is sent to the primary routing 
communication protocol stack (block 308) and the primary 
routing communication protocol stack constructs a CRT 
based on the information form the message. 
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Alternatively, the server stacks may send NEWCONN 
messages directly to the recovered primary routing stack 
either in response to receiving the VIPA list or the 
DVIPA message. In any case, routing of the existing 
5 connections may then be performed by the primary routing 

communication protocol stack. Finally, the backup 
routing communication protocol stack deletes the DVIPA 
and cleans up its routing and DPT tables (block 310) . 
Thus, the routing of the DVIPA is returned to the 

10 recovered stack. 

In the example illustrated in Figure 4, assume that 
the communication protocol stacks 26 and 34 have 
applications with connections routed through the DVIPA of 
the routing communication protocol stack 22 . 

15 Furthermore, the communication protocol stack 3 8 is 

defined as the backup to the communication protocol stack 
22. If the communication protocol stack 22 fails, then 
the communication protocol stacks 26. and 34 send SRVSTAT 
messages to the backup routing communication protocol 

20 stack 38 identifying them as current actual targets. The 

communication protocol stacks 26 and 34 also associate 
the communication protocol stack 3 8 with the DVIPA DVAl 
and send all subsequent messages to the backup routing 
communication protocol stack 38. The communication 

25 protocol stack 38 builds its DPT from the SRVSTAT 

messages receives NEWCONN messages for connections 
through the failed communication protocol stack 22 and 
creates routing information for incorporating in its CRT. 
The backup routing communication protocol stack 38 

3 0 incorporates the routing information into its routing 

table and begins routing messages for the connections 
routed through the failed communication protocol stack. 
The backup routing communication protocol stack 38 may 
also send a DVIPA message to the other communication 
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protocol stacks 26, 30 and 34 to indicate that it is 
backing up the DVIPA DVAl . 

When the primary routing communication protocol 
stack 22 is recovered, it sends a VIPA list to the other 
5 communication protocol stacks 26, 30, 34 and 38. The 

VIPA list message signals the other communication 
protocol stacks 26, 30, 34 and 38 to send SRVSTAT 
messages to the communication protocol stack 22 so as to 
identify current actual targets for the DVIPA DVAl. The 

10 communication protocol stack 22 builds a DPT from the 

SRVSTAT messages. The backup routing communication 
protocol stack 3 8 also generates a NEWCONN message for 
each connection to DVAl routed through the backup routing 
communication protocol stack 38 and sends this message 

15 tot the communication protocol stack 22 . Alternatively, 

the server communication stacks may send NEWCONN messages 
in response to the VIPA list identifying existing 
connections to the DVIPA. In any case, the communication 
protocol stack 22 builds a CRT from the NEWCONN 

20 message (s). The backup routing communication protocol 

stack 38 cleans up its routing tables and deletes DVAl so 
that it no longer performs routing for DVAl. Thus, 
control of DVAl is transferred back to the communication 
protocol stack 22 with limited disruption to the 

2 5 connections. 

As a further example of embodiments of the present 
invention, operations for the movement of dynamic VIPAs, 
whether routable or not, will now be described. As 
mentioned above, a dynamic VIPA may be established by an 

3 0 lOCTL or bind to a VIPA defined in the VIPARange as 

MOVEable NONDIRUPTIVE or in a VIPADEFine statement as 
MOVEable IMMEDiate . In either case, the DVIPA messages 
described above may be utilized to move the VIPA from an 
existing protocol stack to a new protocol stack with the 
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new protocol stack routing the connection to the existing 
protocol stack. Thus, the dynamically routable VIPA 
routing function may be used with non-distributed 
(existing) dynamic VIPAs to allow immediate movement of a 
dynamic VIPA from a first protocol stack to a second 
protocol stack without requiring that all connections to 
the VIPA at the first protocol stack be terminated. 
Also, the routing function may allow connections to the 
first stack to be maintained and new connections created 
to the second protocol stack by routing the old 
connections to the first protocol stack until they 
terminate. Thus, a gradual, non-disruptive takeback of 
connections may be achieved. 

Figures 11 and 12 illustrate operations of a 
communication protocol stack to facilitate the moveable 
VIPA. As seen in Figure 11, when a dynamic VIPA is 
initialized, by a protocol stack it may be determined if 
the VIPA is a moveable nondisrupt ive VIPA (block 500) . 
Initialization of the VIPA may occur, for example, by an 
application binding to a VIPA in a VIPA range which is 
defined as MOVEable NONDISRUPt ive . If so, then the VIPA 
may be advertised to the routing protocol (block 502) . 
Alternatively, if the IP gateway of a cluster of data 
processing systems is OSA Express using Queued Direct 
I/O, the IP Assist function may automatically update the 
OSA Express adapter when a "home list" of a protocol 
stack is updated. Thus, in such an automatic update 
scenario, the operations of block 502 may be skipped. It 
may also be determined if the VIPA is active on another 
stack (block 504) . Such a determination may be made by 
previous messages from the other stack advertising the 
existence of the VIPA. If the VIPA is not active on 
another stack, then the current stack may establish 
connections using the VIPA without using the other stack 
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as routing stack (block 510) . The current stack may also 
create routing and destination port tables as described 
above in the event that the VI PA is moved to another 
stack or in the event that other stacks look to the 
5 current stack as a routing communication protocol stack. 

If there is a VIPA on another stack (block 504) , 
then the current stack receives connection administration 
messages from the other stack or stacks identifying 
existing connections to the stack (block 506). The 

10 current stack builds a routing table from these 

connection administration messages and routes information 
to these existing connections (block 508) . Such a 
communication sequence may result from the advertisement 
that the current stack owns the VIPA. The current stack 

15 may also receive subsequent requests for connections to 

the VIPA and termination messages for existing 
connections to the VIPA so as to manage routing of 
information to the appropriate communication protocol 
stacks as described herein. Thus, ownership of the VIPA 

2 0 may be immediately transferred to a new communication 

protocol stack without disrupting existing connections. 

Figure 12 illustrates operations of a communication 
protocol stack which owns a VIPA in response to a new 
communication protocol stack claiming ownership. As seen 

25 in Figure 12, notification of the VIPA on another 

communication protocol stack is received (block 520) and 
the VIPA is associated with the new communication 
protocol stack (block 522) such that all messages 
concerning new or existing connections are sent to the 

30 new communication protocol stack. It may also be 

determined if there are existing connections to the VIPA 
(block 524) . If no connections exist, then the transfer 
of ownership is complete merely by associating the VIPA 
with the new communication protocol stack and deleting 
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the DVIPA from the current communication protocol stack 
(block 525) . However, if connections exist, then an 
existing connection message is sent to the new 
communication protocol (block 526) . As described herein, 
5 such a message may be for all connections associated with 

the stack or only for those which the stack is an 
endpoint node. Such a message may be a NEWCONN message 
as described above. Furthermore, if the current stack 
was performing any routing functions, these functions are 

10 also transferred to the new communication protocol stack 

and so the routing tables and destination port tables of 
the current communication protocol stack may be purged of 
the connections (block 528) . 

As an example of operations for a moveable VI PA 

15 according to the present invention, assume that the 

communication protocol stack 38, which functions as a 
primary routing communication protocol stack for DVIPA 
DVBl, has not been started. Also assume that the 
communication protocol stack 30 is initialized and an 

20 instance APP B started and binds to a VIPA. in the 

VIPARange statement, such as DVBl. In this case, 
connections to DVBl would be established to the 
communication protocol stack 30. Subsequently, when the 
communication protocol stack 26 was initialized and an 

2 5 instance of APP B bound to DVBl, the communication 

protocol stack 26 would send a VIPA list identifying the 
communication protocol stack 2 6 as the owner of the VIPA 
and, in response, the communication protocol stack 3 0 
would send a NEWCONN- message . The communication protocol 

3 0 stack 2 6 would receive the NEWCONN message and 

incorporate a route for the connection to the 
communication protocol stack 30 into its routing tables. 
The communication protocol stack 3 0 would send all 
subsequent messages regarding the connection to the 
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communication protocol stack 26. When the communication 
protocol stack 38 is initialized, it would assume 
ownership of the VIPA as the primary routing 
communication protocol stack and would send a VIPA list 
5 to the other communication protocol stacks identifying 

itself as such. It may also send a takeback message as 
well to take ownership of the VIPA. The communication 
protocol stacks 30 and 26 which have existing connections 
to the VIPA would send a message identifying the existing 

10 connections to the communication protocol stack 38 which 

would incorporate routing paths for the connections into 
its routing table. Subsequent messages regarding the 
existing connections would be sent to the communication 
protocol stack 3 8 and subsequent connections would be 

15 made through the communication protocol stack 38. Thus, 

ownership of the VIPA was transferred nondisrupt ively 
from the communication protocol stack 30 to the 
communication protocol stack 2 6 to the communication 
protocol stack 38. 

2 0 As used herein, the term "connection administration 

message" refers to messages between communication 
protocol stacks which are utilized to manage the routing 
of TCP/IP messages between the communication protocol 
stacks. Thus, for example, the NEWCONN, TERMCONN and 

25 VIPA lists may be considered connection administration 

messages . 

While the present invention has been described with 
respect to the VIPA distribution function as a part of 
the communication protocol stack, as will be appreciated 
30 by those of skill in the art, such functions may be 

provided as separate functions, objects or applications 
which may cooperate with the communication protocol 
stacks. Furthermore, the present invention has been 
described with reference to particular sequences of 
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operations. However, as will be appreciated by those of 
skill in the art, other sequences may be utilized while 
still benefitting from the teachings of the present 
invention. Thus, while the present invention is 
5 described with respect to a particular division of 

functions or sequences of events, such divisions or 
sequences are merely illustrative of particular 
embodiments of the present invention and the present 
invention should not be construed as limited to such 

10 embodiments . 

Furthermore, while the present invention has been 
described with reference to particular embodiments of the 
present invention in a System/3 90 environment, as will be 
appreciated by those of skill in the art, the present 

15 invention may be embodied in other environments and 

should not be construed as limited to System/3 9 0 but may 
be incorporated into other systems, such as a Unix or 
other environments by associating applications or groups 
of applications with an address rather than a 

2 0 communications adapter. Thus, the present invention may 

be suitable for use in any collection of data processing 
systems which allow sufficient communication to all of 
for the use of dynamic virtual addressing. Accordingly, 
specific references to System/390 systems or facilities, 

25 such as the "coupling facility, " "ESCON, " "Sysplex" or 

the like should not be construed as limiting the present 
invention . 

In the drawings and specification, there have been 
disclosed typical preferred embodiments of the invention 
30 and, although specific terms are employed, they are used 

in a generic and descriptive sense only and not for 
purposes of limitation, the scope of the invention being 
set forth in the following claims. 
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